fix: fall back to getent for users that are not findable in /etc/passwd#183
Conversation
|
FYI, you can test this with the |
dimaqq
left a comment
dimaqq
left a comment
There was a problem hiding this comment.
Fly-by: the change looks good to me.
james-garner-canonical
left a comment
james-garner-canonical
left a comment
There was a problem hiding this comment.
Landing this as-is seems reasonable to me.
I do wonder if we should swallow all errors from trying to run getent the way we are, and also if we should have a test exercising how we fail if getent isn't available.
I don't think these should block landing this feature since Ubuntu should always have getent and 'user not found' is probably our only expected error.
Previously any error from `getent passwd` — including the binary being
missing or NSS misconfiguration — was reported as "unknown user", hiding
the real cause. Inspect the exit code: 2 ("key not found") maps to
`user.UnknownUserError` so callers can still match it with errors.As;
anything else is wrapped with %w. Malformed output is also surfaced
verbatim rather than masquerading as an unknown user.
Add a `getentBinary` package variable so tests can simulate the binary
being absent, and add a test that exercises that path. Tighten the
existing unknown-user test to assert the typed error.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3 participants
The go
User.Lookupmethod on Unix-like systems without ego just looks in the /etc/password file (whereas cgo does a getpwnam check via libc). On some systems, like the Canonical laptops, the user that is trying to run Concierge may not be in/etc/passwdand be loaded from a directory service instead.This PR adds a fallback system where we will run the getent binary. That comes from the
libc-binpackage in Ubuntu, so is very likely to be available (and the worst case is that it's not and we'll fail just as we did before).Fixes #182